1. Field of the Invention
The present invention concerns managing system state for a system having multiple messages for related transactions in a message flow environment, and more particularly concerns nodes in such an environment for granting and releasing, to a selected one of the messages, exclusive access to a system resource.
2. Related Art
To put business enterprise data to more productive use, the data must be moved reliably among different software applications. That is, businesses want applications located anywhere within their enterprise to be linked together, and even to send messages to systems of other business enterprises, such as those of their customers and suppliers. A simple example is of two payroll systems that need to communicate with each other. Numerous issues arise in this effort, not the least of which concerns communication among disparate applications running on heterogeneous networked platforms using diverse data formats. In the payroll example, for instance, both of the systems may have employee names but with a name stored in one field in one system and in more than one field in the other system. Moreover, the problem illustrated by the payroll example is relatively simple. Data produced by one application may have a data structure that is more unrecognizable to another application. It is of course possible to transform data between applications, but as data is shared among more and more systems the overhead becomes unacceptable, and future maintenance becomes a large and often messy job.
This situation has led to an increasing focus on integration tools, such as IBM's WebSphere MQSeries Integrator (“WMQI”), for developing message processing applications with a common Application Programming Interface (API). (“WebSphere MQSeries Integrator” is a trademark of IBM.) An enterprise integration application developed with software such as WMQI typically acts as a distribution hub, i.e., a sort of a broker, for messages passing among other applications, and may accordingly be referred to herein as a “Broker.” In this centralized location, definitions are configured specifying how messages are to be transformed and routed. This arrangement tends to eliminate the need for numerous interfaces between applications and to free developers from worrying about platform differences, such as different operating systems.
This kind of enterprise integration application is typically characterized by graphical tools and a high level flow language for configuring a flow of messages on a structure of interconnected nodes, including numerous predefined nodes, creating what may be referred to as a “workflow” or “message flow” environment. That is, within the Broker, individual functions are assigned to a collection of interconnected nodes, with the processing and transformation activities taking place in the nodes. Through the deployment of predefined and customized nodes, a sophisticated processing environment is built in which nodes perform operations on message data within a message flow, and have the ability to access information outside the message flow, such as information in a database or an external application, and to leave the message flow by placing a message on a queue.
Certain support is typically provided for multithreading in a Broker such as WMQI. A message can be read from a queue to begin the message flow and can be placed into a queue to terminate the flow of the message. There can be multiple flow paths between the input and terminating nodes, with respective messages concurrently flowing through different paths, each message handled by its own thread. Moreover, even if there is only one flow path between the input and terminating nodes, concurrent instances of the same message flow are supported, with each instance processing its own respective message read from the queue.
For such multithreaded messages it is important to maintain system state. For example, two multithreaded transactions, or even two multithreaded messages for the same transaction, may access a common resource, such as a database. The manner in which the threads access the resource may be important for transactional integrity, i.e., for maintaining the system in a proper state. However, in conventional workflow applications processing nodes do not automatically and explicitly maintain transactional integrity of messages flowing through the system. Instead, the developer must carefully maintain transactional integrity within the bounds of the message flow by diligently structuring the Broker application and applying its predefined transactional properties.
One known way to structure a message flow application to maintain transactional integrity among threads is to force related messages to join. See for example, Notani et al., U.S. Pat. No. 6,397,192 B1, “Synchronizing One or More Workflows Using One or More Synchronization-Join Activities That Include Synchronization Logic,” May 28, 2002. However this may cause a performance penalty, particularly when this joining includes forcing multiple-threads to become essentially single-threaded. Therefore, a need exists for improvements in a multithreaded message flow environment to manage multiple messages for related transactions.